Add DecFloat Type connection option to return DECFLOAT as Decimal64/Decimal128 - #1309

The conversions formatted the value with a fixed custom format and then
removed the decimal point, assuming one was present. This threw
ArgumentOutOfRangeException for every value without a fractional part,
e.g. (FbDecFloat)1m, (FbDecFloat)100m, (FbDecFloat)2.0, and for values
smaller than the format's decimal places, e.g. (FbDecFloat)1e-20. It also
dropped the scale of decimals (1.10m became 1.1) and digits beyond 15
decimal places of doubles (7 for floats).

- decimal: converted exactly from its 96-bit integer and scale, so the
  value and its scale are preserved (1.10m -> 110E-2), including -0.
- double/float: converted to the shortest decimal that round-trips to the
  same binary value ("R" format), e.g. 0.1 -> 1E-1, 0.1 + 0.2 ->
  30000000000000004E-17, 1e-20 -> 1E-20; -0.0 -> negative zero.

A converted double may have up to 17 significant digits; sending it to a
DECFLOAT(16) throws OverflowException instead of being silently rounded
(this relies on the encoder range check of the previous commit).

Random.NextInt64() never returns a negative value, so the random doubles
were all positive. Use the full long range and assert both signs are covered.

Parameters: a DECFLOAT parameter only accepted FbDecFloat; any other value
(decimal, double, int, ...) threw InvalidCastException, even when the
parameter was created by AddWithValue with a decimal. Values of type
decimal, double, float, the integral types and BigInteger are now converted
to FbDecFloat (decimal exactly, double/float to the shortest round-trip
value). A value that does not fit the DECFLOAT precision exactly throws
OverflowException instead of being rounded.

Reader: GetDecimal, GetDouble, GetFloat, GetInt16/32/64 and GetByte (and
the matching GetFieldValue<T>) on a DECFLOAT column threw
InvalidCastException because FbDecFloat is not IConvertible. Now:

- GetDecimal: exact, keeping the scale (1.10 -> 1.10m); OverflowException
  when the value cannot be represented exactly (too large, too many digits,
  NaN, infinity).
- GetDouble/GetFloat: nearest value, like on NUMERIC columns; NaN and
  infinities are mapped, out-of-range values become infinity or zero.
- Integer getters: nearest integer, ties to even, as Convert does for
  decimal columns; OverflowException when out of range, NaN or infinity.

FbDecFloat gets the matching public explicit conversions to decimal, double
and float.

- Provider: add net11.0 to TargetFrameworks. No Microsoft.Extensions.Logging.Abstractions
  package reference is needed for net11.0: the assembly ships in the .NET 11 shared
  framework, and NuGet prunes the reference (the nuspec net11.0 group is empty).
- Tests: multi-target FirebirdSql.Data.FirebirdClient.Tests to net10.0;net11.0 so
  TFM-specific code paths are exercised on both.
- tests.ps1: copy the Firebird binaries into, and run the FirebirdClient suites
  from, every provider test TFM output.
- CI: install the .NET 11 SDK (preview quality until 11.0 GA).

.NET 11 introduces the IEEE 754 decimal floating-point types Decimal32,
Decimal64 and Decimal128. Their decimal interchange encoding
(EncodeDecimal/DecodeDecimal, densely packed decimal) is the encoding of
Firebird's DECFLOAT(16)/DECFLOAT(34): the provider's DECFLOAT codec and
.NET agree bit for bit (asserted by a seeded test over random values and all
special values), so the conversions are exact, including the exponent
(1.10 stays 1.10), negative zero, infinities and NaNs, with no text round
trip.

On net11.0 only:

- FbDecFloat: explicit conversions from Decimal32/Decimal64/Decimal128
  (exact) and to Decimal64/Decimal128 (exact, OverflowException when the
  value does not fit).
- Parameters: Decimal128 values infer FbDbType.Dec34, Decimal64 and
  Decimal32 infer FbDbType.Dec16. They can be passed to any numeric
  parameter; a value that does not fit the target exactly (e.g. a 34-digit
  Decimal128 into DECFLOAT(16)) throws OverflowException instead of being
  rounded.
- Reader: GetFieldValue<Decimal128>() and GetFieldValue<Decimal64>() for
  DECFLOAT and the other numeric types (exact, OverflowException when the
  value does not fit).

GetValue()/GetFieldType() still return FbDecFloat for DECFLOAT columns.

Every parameter value reaches DbValue through FbParameter.InternalValue
(FbCommand and FbBatchCommand, sync and async), so Decimal32/64/128 values
are converted to FbDecFloat there. DbValue no longer checks the type of every
value it stores: both clients store decoded row values in DbValue (the managed
client through the constructors, the native client through SetValue), and
those values are never IEEE decimals. DbValue's constructors and SetValue are
back to their previous code.

Adds a batch command test (Decimal64/Decimal128 parameters, bit-exact round
trip), as FbBatchCommand takes the same path.

…/Decimal128

With "DecFloat Type=Ieee754" (FbConnectionStringBuilder.DecFloatType =
FbDecFloatType.Ieee754), DECFLOAT(16) values are returned as
System.Numerics.Decimal64 and DECFLOAT(34) values as Decimal128 by
FbDataReader.GetValue/GetValues/indexers/GetFieldValue<object>,
GetFieldType/GetSchemaTable (so DataTable/DataAdapter columns get those
types), FbCommand.ExecuteScalar and output parameters.

The default, FbDecFloatType.FbDecFloat, keeps the current behavior.
Ieee754 requires .NET 11 or later: on older target frameworks the option is
rejected when the connection string is validated. The conversion is exact
(the field's precision always fits the IEEE type), and the typed accessors
(GetFieldValue<FbDecFloat>, GetDecimal, ...) are unaffected.